home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / info-service / gopher / Unix / gateways / gopher2FTP / ReadMe < prev   
Encoding:
Text File  |  1993-03-26  |  7.3 KB  |  191 lines
  1. This distribution is somewhat obsolete.  This functionality is
  2. bundled with the Unix server.
  3.  
  4. -----------------------------
  5.  
  6.  
  7.  
  8. In this distribution is a small C daemon called g2fd.c.  This is third
  9. incarnation of a Gopher to FTP gateway.  Running this daemon on a UNIX
  10. box gives folks running gopher clients access to all that good stuff
  11. available out there for anonymous ftp.
  12.  
  13. Previous versions were prototypes written in Perl.  The prototype got
  14. so popular that gopher folks going out to get stuff via ftp were
  15. swamping the unix box that was running the gopher-to-ftp daemon. This
  16. version is much more efficient and has reasonably portable (ha!) load
  17. limiting code.  This version has no logging code...  we'll get round to
  18. that by and by.
  19.  
  20. The principle is this: the gopher client connects to the g2fd daemon
  21. and tells it what the name of the ftp site is, (and perhaps what file
  22. it wishes to retrieve from there).  The daemon connects to the remote
  23. host, retrieves a directory listing (or file) via anonymous ftp, and
  24. returns it to the gopher client.  Of course all this happens without
  25. any new knowledge by the gopher client.
  26.  
  27.  
  28. The daemon assumes a nice healthy unixy ftp server at the ftp end...
  29. that is to say it is probably not going to work with funky IBM or
  30. TOPS-20 ftp implementations.  This is left as an exercise for the
  31. hacker...  er... reader.
  32.  
  33. The daemon is designed to be run by inetd as a TCP daemon.
  34. The easiest way to explain how to set it up and how it works
  35. is to use an example.
  36.  
  37. Let us assume that we want to run a gopher to FTP gateway on a machine
  38. called hell.micro.umn.edu at port 70.  If you already have a regular
  39. gopher server running at port 70 (the sanctioned gopher port), on
  40. hell.micro.umn.edu you can run g2fd at some other high numbered
  41. unreserved port; try something over 3000?
  42.  
  43. 1.  Edit the parameters (marked lines right after the #includes).
  44. in g2fd.c for your
  45. local configuration; in this case change the marked lines as follows:
  46.  
  47. /*==============Local parameters to be edited in===============*/
  48. #define    LOCALHOST    "hell.micro.umn.edu"    /* This host's domain name */
  49. #define    LOCALPORT    70            /* This daemon's port */
  50. #define MAXLOAD        8.0            /* For load limit if > 1 */ 
  51. #define    FTP        "/usr/ucb/ftp"        /* To invoke ftp */
  52. #define    UPTIME        "/usr/ucb/uptime"    /* To check loadavg.  Ick. */
  53. #define    LIST        "/tmp/gftpL+"        /* Temp list file prefix */
  54. #define    DATA        "/tmp/gftpD+"        /* Temp data file prefix */
  55. /*=============================================================*/
  56.  
  57. The MAXLOAD parameter specifies how high the load average on the
  58. host can get before the daemon will refuse new connections.
  59.  
  60. You might also check to find the whereabouts of ftp and uptime
  61. (use "whereis ftp" or poke around) and specify the full pathname.
  62.  
  63. The LIST and DATA  strings specify where the daemon is to stash 
  64. temporary files; leave the + on the end.  In this example, temp
  65. files will be placed in /tmp.
  66.  
  67. 2.  Compile the daemon:
  68.  
  69.     make g2fd
  70.  
  71.  
  72. 3.  Become root and place the g2fd file someplace nice (like
  73. /usr/local/bin or /usr/etc or wherever you place stuff like this);
  74. assume we put it in /usr/local/bin.  Make it owned by root and
  75. executable:
  76.  
  77.     chown root g2fd
  78.     chmod 755 g2fd
  79.  
  80.  
  81. 4.  Update /etc/services by adding the following line to the
  82. /etc/services file (note it's a tab between g2fd and 70):
  83.  
  84.     g2fd    70/tcp
  85.  
  86.  
  87. For SUNs running yp, you'll also want to do a make services:
  88.     cd /var/yp
  89.     make services
  90.  
  91. 5. Now update /etc/inetd.conf or /etc/servers:
  92. For SunOS 4.0 or BSD 4.3 systems add the following line to
  93. /etc/inetd.conf:
  94.  
  95. g2fd    stream    tcp    nowait    root    /usr/local/bin/g2fd    %A
  96.  
  97. For Ultrix systems, (which we haven't tested under!)
  98. add the following line to /etc/inetd.conf:
  99.  
  100. g2fd    stream    tcp    nowait    /usr/local/bin/g2fd
  101.  
  102. For A/UX or SunOS 3.5 add a line to /etc/servers:
  103.  
  104. g2fd    tcp    /usr/local/bin/g2fd
  105.  
  106. Note tabs between fields.
  107.  
  108. 6.  Kill and restart the inetd daemon whatever the prescribed way
  109. to do that on your machine.
  110.  
  111. 7.  You can confirm that g2fd is running now at port 70 by
  112. telneting to hell.micro.umn.edu at port 70. Test it out by
  113. typing 
  114.     boombox.micro.umn.edu@/pub/
  115.  
  116. This funky path means "return the directory listing from the
  117. /pub/ directory from boombox.micro.umn.edu."
  118. It should respond by returning the /pub/ ftp directory at
  119. boombox.micro.umn.edu.
  120.  
  121. 8.  Now make some links from a regular gopher server to the g2fd
  122. service.  On a unix server, a link could look like this (on a 
  123. Mac server, do the functional equivalent using Gopher's Helper):
  124.  
  125.     Name=boombox:  Home of POPmail and Gopher Central.
  126.     Type=1
  127.     Port=70
  128.     Path=boombox.micro.umn.edu@/pub/
  129.     Host=hell.micro.umn.edu
  130.  
  131. And you're all set.
  132.  
  133. What happens is that the user sees the full Name (as always), say
  134. "boombox: Home of POPmail and Gopher Central".  It would appear as
  135. a directory (or folder icon on a Mac).  If selected (double-clicked
  136. on a Mac), the client would open a connection to hell.micro.umn.edu
  137. at port 70.  The g2fd daemon would accept.  The client would
  138. then send it the selector string "boombox.micro.umn.edu@/pub/".  The
  139. daemon would interpret this as "Go out to boombox.micro.umn.edu
  140. via anonymous ftp and get a listing of the pub directory."  The
  141. daemon would return this listing to the client in nice gopher
  142. format.  And everything else happens by magic as you would expect.
  143.  
  144. To the client it looks just like any other gopher-type directory.  The
  145. script does assume that files ending in .hqx are BinHex files and gives
  146. them the type 4.  It also makes rash assumptions about the plethora of
  147. DOS binary files (.zip et. al.), and maps them all to a type 5.  The
  148. client can decide what to do with them based on the .xxx extension that
  149. most seem to carry. Finally, it gives tar and Z files a filetype of 9.
  150. And 9 is a new gopher item type (actually the only one we've allocated
  151. since we set up standards for the protocol.  All other files are given
  152. normal type 0: that is text.
  153.  
  154. If your client is capable of handling binary types then it can allow
  155. type 5 and/or type 9 in directory listings.  It should be prepared to
  156. do things based just on the extensions (.xxx) of the files that the
  157. user requests.  In particular, it will need to just read from the
  158. connection until the server closes the connection when sending a binary
  159. file.  So there will be no concluding period, and obviously lines are
  160. meaningless.
  161.  
  162. WATCH OUT: The script has no way of knowing for sure that a file at an
  163. ftp site is binary (other than educated guesses based on the suffix of
  164. the filename), so when it presents gopherized listings, it must show
  165. these files too.  When a client attempts to retrieve a file, the script
  166. can peek into the file and make a much more educated guess as to
  167. whether it contains text.  So it should prevent a client from
  168. transferring totally gonzo binary.  
  169.  
  170. It would probably be wise to place caution ReadMe files out there for
  171. the users.  Also, if possible good gopher administrators would place
  172. the link all the way inside the "pub" or whatever directory at the
  173. server end.  We really don't want users fumbling around inside the bin
  174. or etc directories and attempting to suck down binary files.
  175.  
  176. Once more: the binary question is still open and we need to resolve
  177. that one yet.
  178.  
  179. All credit for this great and simple idea should go to Craig Rice
  180. (cdr@stolaf.edu).  Thanks Craig.
  181.  
  182. The previous Perl script was much enhanced by John Ladwig.
  183.  
  184. Suggestions or bug reports for this daemon are welcome...
  185.  
  186. The capabilities of this daemon will probably get rolled into
  187. the main gopher daemon in the next release.
  188.  
  189. FXA.
  190.  
  191.